Having RecordTypes doesn't seem necessary as the responder could just send back all record types it knows about. Is there value in being able to ask to send back less data here? The same could be argued in other places (e.g. not sending back TransferProtocols we don't support anyway).

I'm planning to remove this, but wanted to leave this as a place for comment if there was demand for it to stay

if we do have it, we should have some recommendation of how we identify types - what are these strings supposed to be?

It doesn't seem overly harmful to have, but it does add another point of complexity in implementation.

+1: if we are to have it, it should be a union of sorts that becomes the formal spec of known record types.

if we are to have it, there must also be a case for "return all types", otherwise we preclude a dumb middlebox from pre-fetching data.

on the whole, this does seem as an unnecessary micro-optimization (at complexity cost), because the number of records a peer can ever have is limited by the number of types that exist, which is a small number. this is not something that can grow arbitrarily, so ... i would vote no here. the rule of thumb being: can the number of returned results grow in a runtime-dependent manner (e.g. # of providers for a cid depends on runtime conditions, vs number of address records is always capped by the number of types of records which is a compile-time constant)

Wasn't sure which identifiers to use here. In particular it feels weird to be mixing text and codes like this without any sort of standard for how we do this.

@Stebalien has occasionally proposed utilizing / (since it's the 0x90 codec) as a way to bridge text + codes although I'm not sure if that applies here.

if we have codes for some of them already, can we make a code for the reframe-multiaddrs alternative to libp2p signed peer records and standardize on codes?

Including raw bytes like this doesn't feel great, although in order to use this peers will likely need to understand this format to send addresses in Identify anyhow so not so bad.

Are there better ideas here given that we can't just do something like the below due to the use of (non-canonically encoded) protobufs in signed peer records?

type PeerRecord struct {
      Multiaddresses [Bytes]
      SeqNo optional Int
      Signature optional Bytes
}

I think this is fine. One variation, purely for convenience, would be:

type Libp2pSignedPeerRecord struct {
  Multiaddresses [Bytes] # copy of the multiaddresses from the record, for the benefit of systems that don't know/want to check signatures
  Libp2pSignedRecord Bytes
}

if we do have it, we should have some recommendation of how we identify types - what are these strings supposed to be?

It doesn't seem overly harmful to have, but it does add another point of complexity in implementation.

if we have codes for some of them already, can we make a code for the reframe-multiaddrs alternative to libp2p signed peer records and standardize on codes?

nit: there presumably isn't a record in the request, this would be in the response

Yep, I didn't update any of the JSON examples yet (marked with TODO)

Does it make sense to return [PeerRecordType] here rather than just a single PeerRecordType since we're allowed to send back a stream of GetPeerAddressesResponse? Probably doesn't hurt, but we might want to build some conventions here.

I'd keep the array. A receiver might want to forward/use results as soon as the first one arrives. They have no good way of knowing that more are coming back to back.